Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sem: simplify generic parameter symbol handling #644

Conversation

zerbina
Copy link
Collaborator

@zerbina zerbina commented Apr 22, 2023

Summary

Simplify type instantiation and logic related to generic parameters in general, by treating complex type expressions in generic contexts as generic expressions, with the symbols of generic parameters and parameters being bound during first-phase lookup already.

On the user-facing side of things, this fixes multiple long-standing issues with undeclared identifier errors for implicitly instantiated types. For example, the following previously failed:

type
  Type[B] = object
    a: typeof(B) # using 'A' here would make it compile!

proc p[A](): TypeOf[A] = discard

discard p[int]()

The is operator now also works properly in when expression of generic objects. An is expression that was not the top-level one (this includes not x is y and x isnot y) only checked for type equality and always evaluated to true when the right-hand side was a concept type.

Another important thing to note is that type expressions used in the header of generic routines are, except for those used in range type constructors, now generic expressions, meaning that non-immediate templates/macros and static statements are only evaluated once the type is instantiated.

On the compiler side of things, interactions with generic parameter symbols simplify, with a lot of conditional logic becoming obsolete. Instantiating types no longer requires opening a scope and adding all the bound types and static values as skType and skConst symbols.

One effect of the change is that generic parameter symbols are now always bound in type expression contexts, but never bound in generic procedure bodies.

Together, this should streamline generic parameter handling, making it more amendable to further changes / improvements in the future.

@zerbina zerbina added refactor Implementation refactor compiler/sem Related to semantic-analysis system of the compiler labels Apr 22, 2023
@zerbina
Copy link
Collaborator Author

zerbina commented Jul 12, 2023

This PR is currently on indefinite hold.

Because of issues related to wildcard generic parameters, the code as is doesn't work, and while I had made some local progress towards fixing them, the impact of the changes on semantic analysis would likely be too large (and the test suite regarding generics not exhaustive enough) at the moment.

Some of the fixes here, like not lifting typedesc return types for macros/templates, and the fix for generic macro/template return types, are standalone and can be split out into separate PRs.

@zerbina
Copy link
Collaborator Author

zerbina commented Oct 17, 2024

Most of the fixes from this PR have been implemented separately in better ways. Closing.

@zerbina zerbina closed this Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/sem Related to semantic-analysis system of the compiler refactor Implementation refactor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant